A note on the security of Higher-Order Threshold Implementations

At ASIACRYPT 2014, Bilgin et al. describe higher-order threshold implementations: a masking countermeasure claiming resistance against higher-order differential power analysis attacks. In this note, we point out that higher-order threshold implementations do not necessarily provide higher-order security. We give as counterexamples two concrete higher-order threshold implementations that exhibit a second order flaw. 1 Higher-Order Threshold Implementations We refer the reader to [1] for background information. Higher-order threshold implementations (HOTI) have the remarkable property of not needing extra randomness during computation, if each sharing (=masked function) satisfies some properties (namely, uniformity). (This extra randomness is usually called refreshing in other publications.) In the rest of this note, we show that higher-order security is not preserved through the composition of arbitrary yet uniform sharings. Thus, it is possible to conceive HOTI designs that are not higher-order secure. 2 A counterexample For the sake of simplicity, in this example we compute on 1 unshared bit, split in 5 shares (one bit per share). We aim at second order security. We define the sharing Fi,j,k for the identity function as follows: on input (a1, . . . , a5) ∈ F2 it outputs (b1, . . . , b5) ∈ F2 as bm = am for m 6∈ {j, k}, bj = aj + ai and bk = ak + ai. This sharing is parametrized by the tuple (i, j, k). A concrete instantiation of the sharing is for example F1,2,3(a1, a2, a3, a4, a5) = (a1, a2 + a1, a3 + a1, a4, a5) as shown in Fig. 1. The reader can verify that Fi,j,k is correct (it computes the identity function), second order non-complete and uniform (as long as i, j, k are all different.)